System for remote game access

ABSTRACT

A system for allowing a user to remotely access a game includes: a game console; a remote console client configured to receive a game control signal; and a remote console server. The remote console server includes an audio and video encoder configured to receive an audio output and a video output from the game console and to convert the audio output and the video output to a network packet. The remote console server also includes: a game controller emulation unit and a network interface configured to send and receive the network packet. The game controller emulation unit is configured to receive a game controller signal from the game console and to send the game controller signal to the remote console client and to receive a game controller input from the remote console client and send the game controller input to the game console.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are hereby incorporated by reference under 37 CFR 1.57.

BACKGROUND OF THE INVENTION

Typical game consoles are designed to output audio and video signals toa display such as a television system. Users generally play consolegames by going physically to the console. A system that allows users toplay console games from remote locations over a network would allowusers to play a console games without physically going to the locationof the game console.

SUMMARY OF THE INVENTION

Embodiments of the present invention enable users to play console gamesfrom remote locations in real-time, over a network. Embodiments alsoprovide for a system to allow users to determine which game consoles areavailable and provide a system to manage the access and accounting formultiple users, thereby creating a virtual arcade.

Embodiments of the present invention bring the game console to the useras opposed to the current static configuration where the user must go tothe console. Embodiments of the present invention are configured toallow remote access to various types of game consoles and are notlimited to systems that are strictly designed for playing games. Gameconsoles include standard computers that are capable of performing manyother functions in addition to allowing the user to play games.Embodiments comprise a remote console server (RCS), which furthercomprises a console virtualization engine (CVE). In certain embodiments,the RCS comprises an audio and video encoder that digitizes andcompresses the audio and video output of a game console and sends themas TCP/IP network packets to a remote console client (RCC). The RCS mayalso comprise a game controller emulation (GME) unit that sends gamecontroller signals from the console to the RCC and receives gamecontroller input from the RCC and passes it to the game console. Inaddition, in certain embodiments the RCS may comprise a memory cardemulation (MCE) unit that emulates the memory card of the game console.

The memory card of the game console is used to save user gameconfiguration for games played on the console. By emulating thisfunction, the RCS allows user game settings to be uploaded from the gameconsole for storing in a repository. The emulation unit also allows usergame setting information to be downloaded to the RCS so that it can beused by the game console. This allows a user to play games on anyvirtualized console, as the user's game configurations are enabled tomigrate to different units. Thus, the RCS preserves the continuity ofgame playing experience for the user, enabling the impression of playingfrom the same game console unit.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic of a remote console server and a game console ofone embodiment of the present invention.

FIG. 2 is a schematic of a system in one embodiment of the presentinvention.

FIG. 3 is a schematic of subsystems used in a remote console client inone embodiment of the present invention.

FIG. 4 is a schematic of a system in one embodiment of the presentinvention.

FIG. 5 is a schematic of a system in one embodiment of the presentinvention.

FIG. 6 is a schematic of a system in one embodiment of the presentinvention.

FIG. 7 is a schematic of a system in one embodiment of the presentinvention.

FIG. 8 is a schematic of a remote console server and a game console ofone embodiment of the present invention.

FIG. 9A is a logic flowchart for a virtual arcade session request in oneembodiment of the present invention.

FIG. 9B is a logic flowchart for a virtual arcade session request in oneembodiment of the present invention.

FIG. 10 is a logic flowchart for a server virtual arcade game sessionprocessing start in one embodiment of the present invention.

FIG. 11 is a flowchart for server game emulation logic in one embodimentof the present invention.

FIG. 12 is a logic flowchart for game removable memory subsystem in oneembodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring initially to FIGS. 1-4, an RCS 100 is configured tocommunicate with a game console 200 and a remote console client (RCC)network 300. The physical connection between the game console 200 andRCS 100 can be wired or wireless. RCS 100 further comprises a consolevirtualization engine (CVE) 110 and a network interface 120. CVE 110further comprises an audio and graphics/video encoder 111, a controlleremulation unit 112, and a memory card emulation unit 113. Game console200 generates an audio and graphics output 211 and receives a gamecontroller input 212 and a memory card input 213. Game console 200further comprises a disk access unit 220 and a network IO unit 230 foraccessing a console game network 210. RCC network 300 comprises at leastone individual RCC 310. In certain embodiments, the various componentsof the system are connected to the internet via a local area network(LAN) 411 and router 412.

RCC 310 regenerates the signals received from audio and graphics output211. RCC 310 also accepts game control signals from the user through agame controller 311, a keyboard 312 or a mouse 313 connected to it.Through a controller translator 314, RCC 310 further encodes andtransmits these game control signals in packet 315 (shown in FIG. 3)back to RCS 100 via virtual game play session manager (VGSM) 375. RCS100 then converts packet 315 to controller input signals 317 incontroller emulation unit 112 expected by game controller input 212 ofgame console 200. In certain embodiments, RCS 100 is configured toreceive game controller signals from the game controller input 212 andsend them to RCC 310. For example, some game controllers are configuredto vibrate or illuminate based on game controller signals received fromgame controller input 212.

In the embodiment shown in FIG. 3, RCC 310 also includes a microphoneinput 350 that passes through an audio encoder 351 and is converted topacket 318. Packet 318 is sent to RCC 310 units connected to RCS 100,thereby allowing users to have verbal interactions while playing orviewing a game on game console 200.

Audio and graphics output 211 of game console 200 is sent through theaudio and graphics encoder 111 of RCS 100 to VGSM 375 of RCC 310. AfterVGSM converts output 211 to a packet 316, a low latency audio and videodecoder 319 generates a video output 320 and an audio/speaker output321. In certain embodiments, RCC 310 also comprises a stream packetreceiver 322 that communicates with a voice chat/audio out decoder 323that is sent to speaker output 321. Stream packet receiver 322 and voicechat/audio out decoder 323 allow multiple users to verbally communicatewith one another while playing a game.

In certain embodiments, the RCS may adapt the video quality and latencyto the available bandwidth by changing encoding parameters to improveusers' real-time experience. The video quality and latency may beadjusted by the user or, alternatively, may be adjusted automatically bythe system. Further, the RCS may adapt the video quality and latencydepending on the type of images being sent to the RCC. For example, inText Mode, the RCS can send images at slow frame rates but highresolutions. This mode may be useful when the user needs to read gametext during game setup or game play. In another embodiment, the Textmode encoding may be implemented as a background process and the datamay be transmitted as a sub-channel to the primary game stream. RCCusers can dynamically switch between real-time interactive game streamand Text Mode views as necessary. Certain embodiments may also comprisea TV Mode, in which the RCS can send video images using highercompression, higher latency and higher quality video transmission.

In certain embodiments, RCS 100 possesses some or all of the followingcapabilities:

1. Identifying game controllers plugged into the user's RCC,automatically querying, and retrieving compatible controllerconfiguration from a global server when the user initiates game play;

2. Caching controller configurations for future use;

3. Automatically loading game help information, such as the function ofgame pad controls in a game;

4. Adjusting to different game console controller types and game savememory emulation system; and

5. Downloading new modes as new console platforms or updates to consoleplatforms become available.

In certain embodiments, RCC 310 possesses some or all of the followingcapabilities:

1. Sufficient computing power to decode and regenerate audio and videostreams from RCS 100 in real-time;

2. TCP/IP network connectivity with sufficient bandwidth to accept thepacket stream from RCS 100;

3. An I/O interface to accept a controller adapter that allows a gamecontroller 311 to be connected or other I/O capabilities that arecapable of generating signals that can be interpreted as game controllerfunctions; and

4. A microphone interface to allow the user to connect microphone 350 toRCC 310.

There are a wide range of devices that are known to meet these criteria.As shown in FIG. 2 for example, RCC 310 may comprise a desktop computer315, a laptop (mobile) computer 320, a hand-held device such as apersonal digital assistant (PDA) 325, or a television set top box 330.Embodiments of this disclosure are compatible with each of theseplatforms as well as other similar devices.

Multi-Player Capability

Software running on RCS 100 enables multiple players to share gameconsole 200, such as is currently available in multi-controller,multiplayer games. Each RCS 100 announces its presence to other RCS 100systems on the local network. Users may then initiate connections toavailable RCS 100 systems.

Each RCC 310 may be logically connected to at least one input devicesuch as game controller 311, keyboard 312 or mouse 313. Controllerinputs from each RCC 310 are forwarded to the designated input on RCS100. An RCC 310 that can control a port on game console 200 is called“active”. Additionally, RCS 100 may allow more users than the gameallows as players to connect in passive or monitor-only sessions. Thesepassive RCCs 310 receive signals from audio and graphics output 211 butno controller input is passed back to RCS 100. Both active and passiveusers may also communicate verbally through their RCCs. Thus, many userscan view a game remotely and virtually experience the feeling of beingin the same room. RCS 100 enables an active RCC 310 to hand over controlof its controller to a passive RCC 310, thereby making the passive RCC310 active and causing the active RCC 310 to become passive.

Desired Characteristics

Certain physical network criteria, such as sufficient downstream networkbandwidth, are beneficial for providing an optimal remote gamingexperience for users. Downstream bandwidth is the network bandwidthneeded to send packets from RCS 100 to the RCC network 300. Depending onthe RCC unit 310 characteristics (display size, resolution and desiredaudio quality), bandwidths of between 256 Kb/sec (portable) and 8 Mb/sec(high definition) are needed per user. This is within the capacity ofwired and wireless local area networks, such as is typically availablein a home or commercial environment. Smaller portable devices generallyrequire less bandwidth because of the smaller display. A wirelessnetwork, for example as may exist at a hotspot can sustain many remoteplay sessions concurrently depending on the network and the specificdevice characteristics. A 54 Mb/sec wireless network at 50% efficiencycould support 50 concurrent remote play users at 384 Kb/sec each.Similarly, the downstream bandwidth of broadband connections(Cable/DSL/Wireless) of 384 Kb/sec and greater is able to support atleast one remote play user. RCS 100 is designed to support networkbandwidth of 100 Mb/sec and higher and is therefore able to host manyusers.

Sufficient upstream bandwidth is also desirable to provide an optimalremote gaming experience for users. Upstream bandwidth is the bandwidthneeded to transmit controller commands from RCC network 300 to RCS 100.A bandwidth of 2 Kb/sec is typically needed for this function.Additionally, voice grade audio for voice sharing typically needs about8 Kb/sec. Thus, a total of 10 Kb/sec is generally needed per user. Thisis within the upstream bandwidth of typical broadband networks whichgenerally have upstream bandwidths of 64 Kb/sec and higher. Local areawired/Wi-Fi networks typically have symmetric bandwidth.

Low network latency is also desirable to provide an optimal remotegaming experience for users. To maintain the experience that usersobtain from direct play of console games, the time for packets to travelfrom RCS 100 to RCC 310 (latency) should be low, of the order of lessthan 20 milliseconds (ms). On a local area network, latencies aregenerally significantly lower (<2 ms). Network latencies across theInternet and wide area networks (WAN), however can vary much moresignificantly. This is generally so when greater geographic distancesexist between the communicating parties. Embodiments of the presentdisclosure will enable an RCC 310 to automatically locate a RCS 100 thatis hosting user-desired games that are “closest” to them (lowestlatency) and thereby help ensure an optimal game experience.

Video and audio encode/decode latency is also desirable to provide anoptimal remote gaming experience for users. Embodiments of the presentdisclosure provide RCS 100 to RCC 310 encode-decode latencies of lessthan 100 ms. This is within the bounds that will ensure user perceptionof direct play experience.

Global Servers

In certain embodiments, remote console play may benefit from thefollowing features:

1. Users may need a unified way of locating RCS 100 and games on thenetwork.

2. Upon locating RCS 100, a method for reserving it for exclusive usemay be needed until the session is terminated.

3. An accounting method that allows for the user to access the devicewithout requiring local re-authentication and conducts appropriate timetracking and billing.

Referring now to FIG. 4, embodiments of the present disclosure compriseone or more global servers that provide these functions, enabling thedistributed network of RCS 100 to be easily accessed by users andproviders. The servers can be owned by a central company that charges apercentage of the fee billed to RCC 310 users who pay to access RCS 100.The central company may also profit from advertisements displayed on RCC310.

In certain embodiments, the following 3 servers can be used to enablethis service to users:

1. Global Registry Server (GRS) 400: For enabling easy discovery ofavailable RCS 100 and games hosted by them.

2. Global Configuration Server (GCS) 420: For persistent storage of usergame settings.

3. Global Authentication Server (GAS) 440: For authenticating access toRCS 100 from RCC 310.

GRS 400, GCS 420 and GAS 440 are connected to the internet via a localarea network (LAN) 411 and router 412. Software on RCS 100 and RCC 310,with user input, communicates with these servers 400, 420 and 440 toensure a user-friendly experience accessing remote play network devicesand services. While GRS 400, GCS 420 and GAS 440 serve differentfunctions within the system, in certain embodiments, all functions couldbe performed by one physical global server.

Global Registry Server (GRS)

In certain embodiments, each game console 200 is allowed to play asingle game at an instant in time. GRS 400 will allow users to registertheir RCS 100 and track/monitor its availability. When RCS 100 becomesbusy because a game is being played on game console 200, RCS 100 reportsthis to GRS 400. Similarly, RCS 100 may regularly register with the FRS400 and report when it becomes available. RCC 310 users search GRS 400to locate and reserve access to game consoles 200 that are accessible tothem. RCS 100 owners register their servers and the games available withGRS 400 and specify who is allowed to access it. Access is defined inthe context of a play cell community, subsequently described in moredetail below.

Global Configuration Server (GCS)

In certain embodiments, the GCS 440 is a persistent store server thatallows users to save and restore their game configuration from GCS 440to game console 200 via attached RCS 100. When a user connects to RCS100 to play a game, the option to download a previous game configurationis provided. Thus, as users play a given game on different physical RCC310 units or RCS 100 units, the perception of continuity in game play isenabled.

Global Authentication Server (GAS)

In certain embodiments, GAS 420 creates and authenticates user accounts.RCC 310 users create accounts by registering on GAS 420. This allowstime auditing and authentication to be done for the use of RCS 100 toplay games. If a specific RCS 100 used is enabled for billing, the RCC310 user's account may be charged and the RCS 100 owner's account may becredited. This single system view enables RCC 310 users to locate anduse any available RCS 100 and authenticate only once for signing ontothe service. The account creation process involves users requestingmembership in play cells. An RCS 100 owner creates a play cell for theRCS 100 registered on GRS 400. RCS 100 owners can open access to theirRCS 100 to other RCC 310 consumers by adding them to their play cellCommunity. RCC 310 users can also request access to community bycontacting the owner of that play cell community.

In certain embodiments, franchise RCS 100 systems are enabled tocommunicate with GRS 400, GAS 420 and GCS 440 to participate in creatinga single directory view of the registration, configuration and accountmanagement to users.

Play Cell Network

Referring now to FIG. 5, through its global servers (GRS 400, GAS 420and GCS 440) and RCC 310 software, certain embodiments of thisdisclosure enable the creation of a shared community or network called aplay cell 450. Play cell 450 is one or more RCS 100 that only members inthat specific play cell 450 can access from their RCC 310. One methodfor creating play cell 450 comprises the following steps:

1. User creates an account on GAS 420.

2. User registers RCS 100 with GRS 400. This creates play cell 450 witha membership of 1, which is the owner of RCS 100. The owner of RCS 100has management privileges over who joins/leaves his/her play cell 450.If the user already owns an existing play cell 450, GRS 400 can add RCS100 to the existing play cell 450, as opposed to creating a new one. Incertain embodiments intended for individual users, each RCS 100 isdesigned to support a relatively small number (for example, two) of gameconsoles 200 concurrently. In other embodiments intended for commercialor franchise use, RCS 100 may support a greater number (for example, tenor more) of game consoles 200.

3. The owner of play cell 450 invites others to use their RCS-enabledconsoles 200 by:

-   -   i. Adding the names of the user accounts or cells that can        access his/her server's play cell 450.    -   ii. Opening the play cell 450 to general use.

In certain embodiments, the RCC 310 has built in instant messaging typefunctions that enable users to:

1. Monitor the status of RCS 100 to determine its availability and torequest access to RCS 100.

2. Notify the user when an RCS 100 become available.

3. Chat with users in their play community.

4. Coordinate the playing of multiplayer games.

5. Manage their contact list and server watch list.

In certain embodiments, users may have access to real-time multimediastreams of live game play through a global web portal system. Gameconsole owners can also expose and manage remote access to their gameconsoles via this web portal.

Franchise Remote Console Server Systems

Certain embodiments enable businesses to deliver game-on-demand servicesfor console games on their local network or via WAN. The systemtechnology is designed for:

1. Serving a large number of consoles (for example, greater than 10);

2. User authentication and accounting; and

3. System administration and management.

These embodiments enable the creation of game-on-demand services(virtual arcades) in malls, shopping centers, hotels, Wi-Fi hot spots,etc. FIG. 5 depicts this system. Multiple RCS units can be managed andfranchised as a common pool through a web portal.

In certain embodiments, messages such as advertisements can be sent toRCC 310 from either RCS 100 or from global servers. Further, users'usage patterns of games played or viewed through either a web portal orfranchise location can be collected and used to target advertisements tousers.

Referring now to FIGS. 6 and 7, certain embodiments of the presentdisclosure include highly scalable Enterprise Remote Console Servers(ERCS) 410 and distribution rights from game manufacturers that willenable businesses to provide on-demand game services. ERCS 410 comprisesthe ability to load games on-demand to the console from a GameRepository Server (GRS) 460 as opposed to a local disk unit. ERCS 410also interfaces with a console management network 410 to link up toother remote console servers. An audit/service control server 470controls the access to the on-demand games and provides record-keepingfunctions. Other embodiments also comprise a disk changer for gameconsole 200. The disk changer is under the control of RCS 100 andenables the user to do remote selection of games from the libraryavailable in the disk changer.

Referring now to FIG. 8, an overview and summary of the interactionbetween game console 200 and remote console server 100 is shown for oneembodiment. The individual functions shown in FIG. 8 are described abovein the discussion of the various embodiments.

Referring now to FIGS. 9A and 9B, a logic flowchart of the initiationsequence used in certain embodiments is shown. As illustrated, a sessionrequest 600 allows a user to enter a game selection 610. A query 630then evaluates whether game selection 610 is a simultaneous playersgame. If so, a player selection 640 is performed before a game playsession 650 is created. After game play session 650 is created, the userjoins a wait queue 660 and waits for a session initiation 670 via asession callback 680. After session initiation 670, a setup connectionsession 690 is created and the controller emulation 700 is configured.The user then plays game 710 until an expiration or termination signal720 is generated, at which time the game completion 730 is accomplished.

Referring now to FIG. 10, a logic flowchart for the session processingused in certain embodiments is shown. As illustrated, an initiation 800of session processing leads to a query 810 of active game users. Ifthere are no active game users, a query 860 is performed to determine ifplayers are waiting in queue. If there are active game users, a query820 determines if the game play time has expired. If play time hasexpired, a notification 830 is sent to the users and session resourcesare freed. If play time has not expired, a query 840 is performed todetermine if the user has terminated the session. If the user has notterminated the session and there are players waiting in queue, a scan870 is performed of the pending session queue. After scan 870, a query880 is performed to determine if the session is ready. If the session isready, the session 890 is then initiated.

Referring now to FIG. 11, a logic flowchart for server game emulationlogic used in certain embodiments is shown. After a receipt 900 of agame pad packet from a user, a conversion 901 is performed on the gamepad packet values. After conversion 901, an activation 902 of theemulation circuits and a reading 903 of outputs from the game client isperformed. Finally, a sending 904 of game outputs to the server isconducted for relaying to the user.

Referring to FIG. 12, a logic flowchart for a game removable memorysubsystem used in certain embodiments is shown. After installation 905of a dual interface memory control to the server, a query 906 determinesif the game session is starting. If the game session is starting, aquery 907 determines if the user has requested a memory download. If so,an acquisition 908 of the memory file is conducted followed by securingsingle access 909 to the memory unit. This is followed by a clearing 910of memory and a re-enablement 911 of the game server to access thememory unit. In certain embodiments, the memory transfer between the RCC310 and the global servers can be accomplished automatically.

If the game session is not starting, a query 912 is performed todetermine if the game session is ending. If so, another query 913determines whether the user has requested a memory upload. If the userhas requested a memory upload, an acquisition 914 of the memory file isconducted, followed by a securement 915 of single access to the memoryunit. This is in turn followed by a reading 916 of game info from thememory unit and a re-enablement 917 of the game server to access thememory unit.

With the benefit of the present disclosure, those having ordinary skillin the art will comprehend that the embodiments described herein may bemodified and applied to a number of additional, different applications,achieving the same or a similar result.

What is claimed is:
 1. A system for enabling a user to remotely access agame, the system comprising: a first plurality of game consoles,including games consoles that include respective game controllerinterfaces, audio outputs, and video outputs; and a remote consoleserver comprising: a console virtualization engine configured toselectively provide remote clients of users access to the firstplurality of game consoles, wherein the console virtualization engine isconfigured to: provide access to a first game console from the firstplurality of game consoles to a user requesting a first game session;receive packetized control signals from a remote game controllerassociated with the requesting user; convert the received packetizedgame control signals to a form compatible with the first game console;receive audio and video data output from the first game console; encodeand packetize the audio and video output data from the first gameconsole; transmit the encoded and packetized audio and video output datafrom the first game console to a client associated the requesting user;store a game configuration, corresponding to the first session of gameplay with the first game console; enable another of the first pluralityof game consoles access to the stored game configuration during a secondgame session of the requesting user.